Global Internet Domain Name System, also referred to as the Domain Name System (DNS), defines a tree of names starting with root, “.”, immediately below which are top level domain names such as “.com” and “.us”. Below top level domain names there are normally additional levels of names. Domain Name System (DNS) was invented as a technology for enabling humans to identify computers, services, and resources connected to a network (e.g., Internet) by corresponding names rather than network addresses (e.g., Internet Protocol (IP) addresses) in a number format. DNS translates human readable names into unique binary information of network devices to enable users to find the devices they need. Unfortunately, conventional DNS is not secure and is highly prone to malicious interception. The insecure nature of DNS has been known to cause substantial loss of privacy, data, and identity theft, among many other problems. For example, one of the ways in which DNS can be exploited is called DNS cache poisoning. When a client device inputs a Uniform Resource Locator (URL) into a client browser, a DNS resolver checks the Internet for the proper name/number translation and location. Typically, DNS will accept the first response or answer obtained without question and direct the client device to the site referred to in the response. The server receiving the DNS response will also cache that information for a period of time until it expires, so upon the next request for that name/number, the site is immediately delivered to the requesting client device. Since users at client devices assume they are getting the correct information, when a malicious system responds to the DNS query first with modified, false information, security of the client device is breached. Not only does that single computer get sent to the wrong place, but if the malicious server is answering for a service provider, then thousands of users can get sent to a rogue system. This misdirection of a URL request can last for hours to days, depending on how long the server stores the information, and all the other DNS servers that propagate the information can also be affected. The imminent dangers posed by a rogue site include delivering malware, committing fraud, and stealing personal or sensitive information.
To overcome some of the drawbacks of conventional DNS systems, Domain Name System Security Extensions (DNSSEC) were introduced as an attempt to add security to DNS while maintaining the backward compatibility needed to scale with the Internet as a whole. DNSSEC adds a digital signature to ensure the authenticity of certain types of DNS transactions and, therefore, the integrity of the information. DNSSEC is a series of DNS protocol extensions, described in Request for Comments (RFCs) 4033, 4034, and 4035, hereby incorporated by reference in their entireties, that ensures the integrity of data returned by domain name lookups by incorporating a chain of trust into the DNS hierarchy. The chain is built using public key infrastructure (PKI), with each link in the chain consisting of a public/private key pair. Deploying DNSSEC involves signing zones with public/private key encryption and returning DNS responses with signatures. A client's trust in the signatures is based on the chain of trust established across administrative boundaries, from parent to child zone, using a Domain Name System Key (DNSKEY) and delegation signer (DS) resource records, which were not defined in DNS specifications. In DNSSEC, since an unbroken chain of trust is established from the root at the top through the top-level domain (TLD) and down to individual registrants, the client device's answer always receives an authenticated response. All zones are authenticated by “signing,” in that a publisher of a zone signs that zone prior to publication, and the parent of that zone publishes the keys of that zone. With millions of zones, it is likely that the keys expire before the DNS records are updated. As a result, zone operators require techniques to automatically allocate keys to DNS records before these keys expire. Unfortunately, conventional systems are unable to handle management of keys for DNSSEC. Further, conventional DNS systems are unable to translate non-DNSSEC responses to DNSSEC responses.
Furthermore, conventional network systems are unable to handle DNSSEC signatures when zone names are dynamically updated. For example, consider a zone name that was previously signed statically. Subsequently, when the zone name is updated or changed, the DNSSEC signature for the earlier version of the zone is rendered invalid, and since the new zone is unsigned, there is no method for conventional systems to automatically enable DNSSEC for the dynamic update to the zone in real time.
In another related scenario, for global server load balancing (GSLB)-type DNS responses in which the Internet Protocol (IP) answer in a response to a request from a client device can change depending on the requesting client device, conventional systems are unable to provide DNSSEC for such dynamically changing domain names while at the same time performing global load balancing. Since GSLB can provide different answers to different clients for the same domain name, GSLB and DNSSEC are fundamentally at odds in the original design specifications. DNSSEC, as originally conceived, was focused solely on traditional static DNS and never considered the requirements of GSLB, or intelligent DNS. Unfortunately it is difficult for conventional systems to provide DNSSEC for dynamic DNS, and to provide DNSSEC for GSLB-type DNS responses in a load balancing scenario where there might be two different answers for the same request and the GSLB has to forward a signed response to the client device.